Add grid movement and resizing functions #64
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR and its intentions look quite good to me. I have only one question: how do you set the width and height of the grid? |
|
These functions re-use existing grid properties set using `waitron
window_put_in_grid`. If no grid properties exist on a window when
calling these functions, they return immediatly without modifying the
window's geometry.
Tudor Roman writes:
… This PR and its intentions look quite good to me. I have only one question: how do you set the width and height of the grid?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
tudurom
requested changes
Oct 30, 2019
These two functions respectively move and resize windows that were previously put in a grid using window_put_in_grid. A grid struct is added to clients to save the current client position in the grid.
These name changes reflect the fact that a gridded window is special but not maximized.
A window should not be rest if it is not special to begin with
|
Done! |
|
Looks great! One last question: what happens to the gridded windows if you change the parameters of the grid? |
tudurom
approved these changes
Nov 8, 2019
|
Do you mean if a window is in a 9x9 grid and it is changed to another value (eg. 5x5)? Then it should simply redraw the window in the new grid given that grid parameter can only be changed by |
|
Looks legit then. |
|
@tudurom Nice catch. I never monocle or maximize windows so I didn't test these cases properly. |
|
it's not about monocling or maximizing, but just moving or resizing the window normally while in grid state. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to reopen PR #57.
It has been a year since I closed the original PR since the two grid-based operations I proposed could be implemented outside of windowchef with the help of wmutils, and it seemed good enough for me at the time.
After a year of using different window managers, namely windowchef, mwm (my fork of windowchef), fvwm, wmutils, cwm, awesome, qtile and bspwm, I am still struggling to settle on a wm for good mainly because none of these wms have grid operations baked-in by default. I considered several other options before opening this PR:
Since neither of these options seem to cut it, I would like to merge these two functions to windowchef's core. I have other cool grid operations in mind that could be easily be implemented if this PR is merged (notably increasing and decreasing grid size on all four sides simultaneously).
Of course I would like to know what other windowchef users think of these changes and if they would be interested in using these kind of operations. If no one is really interested I think I will stick with maintaining my own branch.